This is not the best fix yet, but it is a quick fix. @noisysocks you had been bitten by the disappearing captions, do you think this approach could work, and later move to calling the REST media api and update the caption for each attachment based on the GTB gallery 's rich text value?

This definitely works better, in that there are no lost captions. That's a massive win on its own. 🙌

There's still a couple weird experiences that occur under the following conditions:

1. Insert a gallery, add a caption to (at least) one image.
2. Hit the "Edit" icon to open the media modal.
3. Add a new, different caption for that image. Hit "Update Gallery"
4. Notice that the new caption you added is not present, since it's overwritten by the one entered in Gutenberg.

It'd be great if we could offer logic to see if the caption has been changed since the Media modal was opened, and then update the caption in Gutenberg to match. Not sure if that's possible though.

And also:

1. Insert a gallery, include an image with an existing caption.
2. In Gutenberg, remove the existing caption.
3. Hit the "Edit" icon to open the media modal.
4. Do not make changes, but hit "Update Gallery" to return the Gallery block.
5. Notice that the original caption from step 1 is now present again.

If you modify (not delete) the caption in Gutenberg, the caption will not be overwritten by the one in the media modal. When comparing to that, the behavior in step 5 is inconsistent. I'd expect the editor to know that if I've manually deleted a caption, it's intentionally gone and should not be replaced so easily.

In general though, I'm super-glad that this means no more lost captions, so it's a definite improvement. 👍

I've updated the code to @noisysocks 's review and also @kjellr I have added the following behaviour:

• if you edit the caption in the gallery modal it will update the one in GTB

Feels a lot better now, let me know if you can take it for another spin :)

@gziolo @talldan can you please shine some light here as I can't seem to be able to figure out what is wrong with this failing test:

npm run test-unit -- --testPathPattern test/integration/full-content/full-content.spec.js

The only thing that causes it to fail appears to be the new item in block.js (attachmentCaption). All the other code passes all tests (I tested by applying each change incrementally).

As soon as I add

	"attachmentCaption": {
		"type": "string"
	}

to the block.json the test fails. The error is:

● full post content fixture › core__gallery

    expect(jest.fn()).not.toHaveErrored(expected)

    Expected mock function not to be called but it was called with:
    ["Unknown source type \"undefined\""]

      32 | 	function assertExpectedCalls() {
      33 | 		if ( spy.assertionsNumber === 0 && spy.mock.calls.length > 0 ) {
    > 34 | 			expect( console ).not[ matcherName ]();
         | 			^
      35 | 		}
      36 | 	}
      37 |

      at Object.assertExpectedCalls (packages/jest-console/src/index.js:34:4)

  ● full post content fixture › core__gallery__columns

    expect(jest.fn()).not.toHaveErrored(expected)

    Expected mock function not to be called but it was called with:
    ["Unknown source type \"undefined\""]

      32 | 	function assertExpectedCalls() {
      33 | 		if ( spy.assertionsNumber === 0 && spy.mock.calls.length > 0 ) {
    > 34 | 			expect( console ).not[ matcherName ]();
         | 			^
      35 | 		}
      36 | 	}
      37 |

      at Object.assertExpectedCalls (packages/jest-console/src/index.js:34:4)

If you test be sure to run npm run test-unit -- --testPathPattern --clearCache test/integration/full-content/full-content.spec.js to make sure you don't get false positives.

As soon as I add

	"attachmentCaption": {
		"type": "string"
	}

Isn't it missing source and attribute properties? See how the parent source with value query should be structured: https://github.com/WordPress/gutenberg/blob/master/docs/designers-developers/developers/block-api/block-attributes.md#query

Indeed @gziolo that was the issue!

I have refactored the code and now the failing test works.

Instead of adding a caption attribute to each image in the gallery I added an attachmentCaptions array attribute of the gallery ( props @talldan ) and that avoided the need to specify a selector and source.

I discovered one more issue when testing it. Steps to reproduce:

• add captions in Media library
• update captions in Gallery
• save and reload
• open Media library for the gallery and click Update Gallery
• captions get replaced even don't modified

@gziolo the bug you found here is not really solvable without tying up the gallery component to the media gallery in WP, as for fixing that we need to monitor the state of the attachments in the modal and only update the component if that state is "dirty".

I would push forward with things as they are, what do you think?